Diagnostics routines consist of a series of instructions executed by the CPU within the computer system to allow self-diagnosis. For years, computers have been provided with diagnostic routines that test and report on the operational status or functionality of components within the computer, allowing an interested party to repair or replace components that are not functioning to the desired degree.
Diagnostics code is sometimes stored on disk and retrieved therefrom for execution by the CPU. One advantage of disk-based diagnostics is that disks provide a relatively large area in which to store code, allowing diagnostics routines to be relatively sophisticated and thorough in their testing and reporting. Unfortunately, diagnostics routines are frequently invoked when components in the computer are not completely functional. To successfully retrieve and execute disk-based diagnostics, the following components must be fully functional: CPU, address and data buses, bus controller, disk drive controller, disk drive and keyboard. If any significant information is to be relayed back to the user, a display device or a printer and their associated interface hardware must also be fully functional. It is apparent therefore that if any one of these components is not fully functional, the diagnostics may not execute or interact with the user properly.
One solution to the above-noted problem with disk-based diagnostics was solved in part by embedding diagnostics code in solid state memory within the computer. Thus, read-only memory ("ROM"), for instance, was employed to store diagnostics as firmware. One type of embedded diagnostics is power-on self-test ("POST") diagnostics, generally stored in basic input-output system ("BIOS") ROM in personal computers. POST is a series of tests that the computer performs on its components each time the computer is turned on. POST begins by reading system configuration information that has either been hard-wired or stored in non-volatile memory. It then checks random access memory ("RAM") by writing to and reading from the RAM to ensure proper operation. POST next examines the disk drives to confirm that they match the system configuration information. Lastly, POST initiates the loading of the operating system, "booting" the computer. Failure during execution of POST isolates the fault area for proper diagnosis. Each phase of the POST routine involves a check of the computer systems major components: the memory, hard-disk drive, diskette drive and operating system.
In contrast to disk-based diagnostics, embedded (or ROM-based) diagnostics require the following components to function: CPU, address and data buses, bus controller and keyboard. Again, if any significant information is to be relayed back to the user, a display device or printer and their associated interface hardware must also be fully functional. Although ROM-based diagnostics are typically required to fit within a smaller space and therefore do not have the luxury of being as thorough as disk-based diagnostics, it is apparent that fewer components need be functional to successfully retrieve and execute embedded diagnostics.
As will be more thoroughly described later, personal computers have a unique bus structure comprising a relatively fast "host" bus that directly connects the CPU and system RAM. A slower input/output ("I/O") bus provides a connection to BIOS ROM and peripheral interfaces (or "slots") that, in typical IBM-compatible personal computers are of an extended industry-standard architecture ("EISA"), allowing peripheral cards to be inserted into the slots to add function to the system. A bus controller joins the host and I/O buses together to allow communication therebetween. The bus controller typically contains interface logic allowing the host and I/O buses to trade data back and forth despite speed differences. The bus controller also contains bus controller memory, usually ROM, that stores data used in conjunction with the interface logic to allow communication between the two buses.
Since the CPU and BIOS ROM are coupled to the host and I/O buses, respectively, retrieval of ROM-based POST diagnostics depends on the full functioning of both buses. If the computer fails to retrieve POST diagnostics, the user must assume that a problem exists either in the CPU, the host or I/O buses, the bus controller, the ROM BIOS, any one of the EISA slots or in the display and its associated interface hardware. Therefore, even ROM-based diagnostics are unable to localize problems to a fewer number of components than this if they cannot be successfully retrieved for execution. (The ability of diagnostics to localize or isolate faults can be thought of as its "resolution," a higher resolution being desirable for obvious reasons.)
The issue of minimizing the number of components required to retrieve and execute diagnostics is not merely theoretical. In practice, EISA peripheral cards introduce many opportunities for faults to occur. These cards are complex, containing many devices per card. Furthermore, these cards reside in physically long slots containing many electrical connections. Failure of any one of the devices on any one of the cards or a fault occurring in any one of the slots can short circuit the I/O bus, potentially completely disabling it. In addition, failure of the BIOS ROM can render POST unloadable and therefore nonexecutable.
Thus, a problem arises when BIOS POST is not available to diagnose the computer. Clearly, there exists a need in the art to more locally diagnose faults in a computer when BIOS POST is unable to load for execution, namely, when a fault prevents the CPU from retrieving POST instructions from ROM.